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ABSTRACT 

Deep Space Network (DSN) resource scheduling is the process of distributing 
ground-based facilities to track multiple spacecraft. The Jet Propulsion 
Laboratory has carried out extensive research to find ways of automating 
this process in an effort to reduce time and manpower costs. This paper 
presents a resource-scheduling system entitled Plan-It with a description of 

its design philosophy. Plan-It's current on-line usage and limitations in 
scheduling the resources of the DSN arc discussed, along with potential 
enhancements for DSN application. 

INTRODUCTION 

Scheduling is believed to be one of the most difficult issues artificial 
intelligence (AI) has attempted to resolve. This paper addresses the how and 

why of AI structures and techniques which were used in resolving the DSN 
Resource Allocation scheduling problem. Finally, the results, which caused a 

factor of six speed-up in the schedule generation process, will be discussed. 

This paper encompasses three main topics. The first part of the paper 
describes the constraints and requirements of the DSN Resource Allocation 
scheduling problem, followed by a description of the design philosophy 
behind the AI scheduling system Plan-It, providing the conceptual 

background for this approach. The remaining portion of the paper will 
discuss Plan-It integration and application to DSN Resource Allocation 
scheduling, along with what has been learned from the task. 



DSN RESOURCE ALLOCATION PROBLEM DESCRIPTION 


The Deep Space Network is a worldwide system of tracking antennas, 
consisting of three ground stations spaced 120 degrees in longitude from 
each other. The stations are located in Canberra, Australia; Madrid, Spain; 

and Goldstone, California. As the earth rotates, this geographical 

arrangement of stations ensures that a spacecraft will be visible to at least 

one ground station at any time. Each station has a minimum of three 
antennas, two 34-meter dishes (one with receiver only, the other with a 
transmitter) and a 64-meter dish antenna. 

Scheduling DSN support for tracking spacecraft is a very difficult 
problem, involving many dynamic factors that influence or even change a 
scheduler's strategy from month to month. The schedule is based on a set of 
constraints consisting of viewperiods, project requests, and DSN system 
requirements. 

Viewperiods are time intervals in which radio dishes have line of sight to 
their targets. This line of sight is required to monitor the signal from a 
particular spacecraft or to uplink commands. When the DSN antenna is used 
for radar imagery of a planet, the planet must be viewable by the antenna. 
These time intervals may also be referred to as time windows. 


Project demands upon the system fall into two major categories. The first 
consists of viewperiod-dependent requirements that a project levies upon the 
DSN. Flight projects usually submit a document containing these time- 
specific tracking requests for the spacecraft and the minimum antenna 
tracking requirements for the project. For instance, a project may require 

ten continuous hours of coverage in duration once a day on a 64-meter 

antenna. This request not only implies multiple usage of an antenna 

resource, but also implies viewperiod restrictions on where the activities 
may be placed in the schedule. Some non-spacecraft requests are also 

viewperiod dependent, if the project wishes to track a planet or a quasar. 

The second category of project requests arc known as non-viewperiod- 
dependent requests, and deal with non-time dependent observations, such as 
certain classes of radio astronomy. These may be in the same format as that of 
the first category, but contain no target-timing restriction. Both categories 
of requests have two types of requests: generic and specific. The generic 

request indicates multiple activities occurring in the schedule, with some 
time-dependence relationship between them. The specific request speefies a 
specific date, time, antenna, and duration which a project requires for 
antenna coverage. 

The DSN also imposes many constraints on the system in the form of 
station maintenance requirements. Each antenna requires a certain amount 
of maintenance, usually eight hours a week. This maintenance activity is 
further constrained by not allowing personnel to cross workshift boundaries 
at the station. There are also times when the station is unmanned, so no 

requested activity may be scheduled during such time. Other DSN activities 


may be antenna upgrades, antenna calibration, and special activities. 

In addition to the activities and constraints listed above, the scheduler 

must observe certain scheduling techniques which may further constrain 

the schedule. For example, no two antennas may simultaneously track the 

same spacecraft for more than 30 minutes, unless simultaneous tracking was 

specifically requested by the project. This limitation/restriction is used to 
maximize use of scarce antenna time. 

Another potential problem the scheduler must address is viewperiod 
overlap among two spacecraft, causing a conflict in their tracking requests. 

This conflict forces the scheduler to work out some kind of compromise, such 
as juggling the projects' requests between other radio antennas or stations, 
or arranging some time-sharing schedule on an antenna between the two 

projects. These are just two of the many different strategies available to the 
scheduler in resolving this conflict. 

The amount of constraints and the number of spacecraft requiring 

tracking yield an incredible number of solutions to a schedule for a 

particular situation. The scheduler's job is to find the solution which best 
optimizes antenna usage, meeting at least the minimum tracking 

requirements of each project. 

The preceding text has described but a few of the basic factors a scheduler 
must consider in establishing a basic DSN schedule. However, there are 
many other special requests and situations which may change this situation. 

For example, when a project has a planetary encounter, all of that project's 

requests become specific requests, which now provide for continuous 
spacecraft tracking for most of the encounter period. Two or more antennas 

may be used in tracking the spacecraft simultaneously for hours at a time. 

These types of constantly fluctuating constraints make the DSN scheduling 
problem a unique one for which the search for a better solution still 
continues. 

A significant contributing factor to the problem with the DSN Resource 

allocation plan is that as spacecraft get farther and farther away from earth, 

a larger diameter antenna is required to pick up the signal from the 
spacecraft. And since there arc few antennas capable of picking up deep 
space signals, there is a great deal of competition between the projects for 

the large antenna resources. 

As the number of projects requiring support increased over the years, and 
more special events occurred closer together, each requiring more and more 

support, it became increasingly more difficult to produce a realistic schedule 

in a reasonable amount of time. To overcome this difficulty the DSN Resource 

Allocation Group was formed to develop an automated process to reduce 
preparation time and enhance reliability of the schedule. The proposed 
process is split into two parts. The first part consists of the Computer-Aided 
Resource Allocation and Planning system (CARPA), which provides an initial 
version of the schedule after all the constraints and requests have been 

entered into the system. This was a batch-mode scheduling system that uses 
a dynamic priority bin-packing technique. The second part consists of 



manually refining the plan to fit a particular situation. 

Each part of the process, however, has its own special problems. A major 
problem in the refining process is that the conditions for which a schedule 
was produced may drastically change as the timeframe to implement the 
schedule approaches. This sometimes requires massive changes to a schedule, 
which must be made quickly and accurately. Excessive delays can cause 
further problems in the DSN schedule because the delays may impact a 
project's future inputs in planning communications with its respective 
spacecraft. Hence a need exists to further automate the process. 


DSN RESOURCE ALLOCATION PLAN-IT OPERATION 


Plan-It was developed to address the final refinement or tweaking portion 
of the scheduling process. The DSN scheduling problem was addressed by the 
resource-scheduling system Plan-It operating in several conceptual modes, 
from the most primitive to almost fully automatic. Another requirement 
Plan-It had to meet was the ability to interface with CARPA. 

The figures on the following page show some of the capabilities a user 
can invoke in Plan-It on a typical DSN schedule. Figure 1 shows a menu of 
statistics, giving the user a quantitative measure of how the radio dishes are 
being used. Figure 2 shows the user mousing on a black conflict area to 
gather further information about that particular conflict. Menu interaction 
is the main user interface to the program. Every operation is mouse driven. 
The menus are accessed successively through a tree structure applicable to a 

particular task category, such as editing, data i/o, strategy implementation 

and modification, and graphical display control. The functions selected from 
the menus direct the tool to do different tasks. The major selectable functions 
are graphical manipulation, data i/o, schedule manipulation and 
verification. 

The graphical display and user’s ability to manipulate it maximize the 
bandwidth of information that passes between the person and the program. 
Each user has his own way of wanting to sec how activities lay out in the 
schedule. To satisfy this need, Plan-It enables the user to dynamically 

reorder requests and resource lines on the screen. This further enhances 
the user-natural interface so a person can intuitively resolve conflict and 
opportunity patterns seen on the screen. Further capabilities the user 
possesses with Plan-It are redefining the relative sizes of the activity- 
plotting pane and the resource line pane. In order not to overwhelm the 

user with an abundance of scheduling data, the Plan-It screen consists of two 

major panes acting as small view windows on a much larger scratchpad of 

the schedule timeline. If the user wishes to concentrate only on a few 
resources but sec more of the activity layout, he changes the relative 
proportions between the two windows. The final graphical manipulation 

tool the user has at his disposal is the ability to change the frequency that 

Plan-It updates its windows. By default, Plan-It will update its windows 

whenever any action occurs. If the user does not wish to see all of the 
intermediate action taking place during a task execution, he can change the 




Figure 2* DSN Plan-It Display. Top pane shows information on the 
conflict area the user had moused on. 
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frequency of update to occur at whatever time interval he desires. 

Via the menu interface, the user loads in the scheduling problem and data 
files. There are several different types of files Plan-It would accept for DSN 
scheduling, ranging from Plan-It's initialization files, viewperiod or 

targetting files, and the schedule file output from CARPA. The user's task is 

to iterate on the input requests or partially generated schedule and to 

finalize the schedule. During any point of the operation of Plan-It, the user 

can request via a menu to either save the present state of the schedule or 

view statistics of the resource usage. The statistics gives the user another 

quantitative means of measuring his progress toward completion of the 

schedule, rather than the graphical view that is always present in Plan-It. 
The saved schedule file can be later loaded in to resume scheduling from that 

point. 


DSN RESOURCE ALLOCATION SCHEDULE GENERATION PROCESS 


CARPA generates the initial schedule. After CARPA completes this phase 
of the scheduling process, the CARPA schedule file is transferred to Plan-It 
for further refinements. In many instances CARPA adequately resolves the 
initial schedule with some lower priority requests deleted. Once Plan-It 

receives the CARPA lilc, the deleted requests are brought back into the 
schedule. The resource lines representing the radio antennas utilized by the 
requests graphically depict the conflict areas. The user may mouse on the 
conflict area to obtain further information on the exact time frame and 

requests or activities contributing to the conflict. Seeing the conflicts and 

opportunities motivates the user to cither edit or invoke specific heuristics to 
further resolve the schedule. This display representation can be seen in the 

figures under the menus. After many cycles of iteration between the user 

and Plan-It, the schedule will finally be completed. 

This mode of operation shows that the Plan-It scheduling process is totally 
user-controlled. As the user edits the schedule, he supplies the intuition and 

motivation to apply and guide the supplied Plan-It heuristics, called 
strategies. The user-natural" graphical interface of the program allows the 
user to see conflicts and opportunities as they arise from previous actions in 
Plan-It, whether initiated by him or the strategies. Upon viewing the 
results, the user can edit directly or invoke other strategies. This is the 
circular-action cycle that the user cooperating with the Plan-It employs to 
produce a schedule. 

The most utilitized concept in the Plan-It system is the strategies. 
Strategics act as a library of simple DSN scheduling heuristics for use by the 

Resource Allocation Team. These strategics may be scoped by user-imposed 
constraints or modifications, specified by strategy-modification menus. For 
example, in DSN scheduling there is an activity-expansion strategy, the 

purpose of which is to expand any activity or request to its maximum 
allowable duration without causing conflicts. The fact that the user does not 

have to be precise on the amount of expansion or which activities to expand 
demonstrates the robustness of these strategics. Also, the strategy may be 


modified by the user to expand about the middle of the activity or expand 
forward or even backwards. The user may further scope the strategy to take 
action only on non-conflicting activities of a certain class of projects that 
only use specific radio dishes within particular intervals of time. This broad 
flexibility of modifying the strategy further enhances the user interaction 
in a more satisfying scheduling process. 


WHAT’S BEEN LEARNED 


One thing learned from watching the Resource Allocation Team schedule 

the DSN is that a scheduler tends to avoid resolving the schedule in a 
chronological order. This jumping about to different time frames on the 
schedule during the scheduling process is a result of changing perspective 
or focus level. People look for opportunities and quick fixes. Initially, during 
the early phases of schedule development, the user lays out the requests in 
the schedule at their preferred locations and applies global strategies. This 
defines the general layout of the schedule. This action may produce conflicts 
throughout the schedule, but the user usually is not concerned with them 
until later, unless by changing his focus level he can quickly resolve a 
conflict that may appear during that process. As the user goes through the 
Plan-It action cycle, the types or pattern of conflicts shown cause the user to 
localize his focus level to the particular conflict or opportunity at hand. At 
this point, he may edit the specific activity, causing the conflict or invoking 
a strategy on the conflict itself to resolve it. Both the Plan-lt strategies and 
the user monitor their performance from the resource lines. Presently, only 
the user is knowledgeable enough to change focus level and choose the order 
of invoking the strategics. 

The last and most important feature emphasized in Plan-It’s creation is 
cooperation with people. Approaching a complicated scheduling problem in 

a top-down, time-ordered programmatic manner does not work. Knowledge of 

the problem domain must be gathered from seeing how people deal with it. 

In the DSN scheduling domain, resource contention and tracking 

opportunities play a major role in determining how a person allocates his 
time and effort in resolving the schedule. Presently, Plan-It views the 
scheduling problem solely from one basic perspective: the resource lines. 

This single viewpoint forces the Plan-It strategies to be more algorithmic 
rather than intuitive driven, thus limiting the scheduling-resolving 

capabilities of Plan-It. But because the person actually secs what Plan-It 
secs, he can supply the conflict pattern and opportunity recognition, 
changing perspective and focus control as needed to resolve a scheduling 
problem. 


CONCLUSION 


Originally the Resource Allocation Team generated schedules manually. 
This manual operation was reduced in part by CARPA. However, even with 
an initial computer-generated schedule, the Resource Allocation team was 


barely able to keep pace with the realtime generation of schedules, taking 
nearly a month to generate one month s schedule. The close interaction 
between Plan-It and the scheduler resulted in a rapid turnaround time for 
producing schedules. It is now possible to generate schedules for an entire 
year within two months. Plan-It's user-natural concept and graphical 

display increase the user's scheduling prowess by enabling him to readily 
see the results of the actions he performs in the schedule itself. But in spite 
of this improvement in scheduling performance, additional research is 
needed to address the issue of incorporating the user's intuitive abilities into 
Plan-It. 
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